Depuis quelques semaines, Nintendo se fâche tout rouge contre les importateurs / revendeurs de cartouches pirates pour DS. Ces cartouches, appelées Linkers, permettent de mettre dans votre console des dizaines de jeux, en passant par un ordinateur. Je vous passe les détails, mais évidemment, la tactique de Nintendo se base sur des recours "classiques", avocats & co. En attendant, les nouveautés DS sont piratées plus vite que leur ombre sur Internet. Et ça commence à agacer certains éditeurs, Square-Enix en tête.

Et paf, du coup, comme au bon vieux temps de l'Amiga / Atari ST et autres usines à dupliquer les disquettes, la guerre reprend de plus belle entre hackers et développeurs de jeux. Dernière passe d'arme "amusante" en date, la protection de Final Fantasy CC : Ring of Fates, surnommée avec humour Moggle of Death (MoD). Cette dernière est basée sur un timer interne, qui fait s'afficher un bel écran "Thank You for Playing" au bout de 20 minutes de jeu environ. La grande classe.

 

 

Il n'en fallait pas plus pour réveiller une communauté de hackers qui n'attendait que ça pour s'amuser. Du coup, sur certains forums américains, plutôt peuplé de jeunes boutonneux collectionneurs de jeux qu'ils ne finiront jamais, on trouve des posts d'aliens, qui retournent la protection du codeur de Square-Enix comme une chaussette. Je vous copie un exemple en V.O., pour le fun, à la fin de cette news, dont le but est simplement de signaler que OUI, ayé, c'est la guerre, comme au bon vieux temps. Mais à ce jeu-là, les éditeurs n'ont jamais gagné.

Some (wrong) things have been said about the "protection" Square-Enix (US) put in the US(/EU) FFCC games (like it was checking if the executables have been modified), so after an afternoon of researches here is the "truth" about it :

The protection is based on the ARM9 DMA3 source address, and not the game CRC.

While the game starts (NDS power on), it launches timer0, and then a bit later it reads its value. This 32-bits value is written to 0x020FB594. The game also checks the DMA3 source address's value (0ed or not 0ed ; the value should be 0ed on the real hardware, not 0ed if the game is run from some devices that don't clean up their mess).

After that the game makes 0x100 - (sum of 3 first bytes of timer0) (+0x80 if the DMA3 source address is 0ed), and writes that byte at 0x020FB597. So if the DMA3 source value is zeroed, the sum of all bytes at 0x020FB594~0x020FB597 ends with 0x80. If the DMA3 source address is not zeroed, it ends with 0x00.

Then, when going through some doors (like going back in the village after seing the mogs at the start of the game), the game verifies that the sum of the 4 bytes at 0x020FB594 ends with 0x80. If not (ie. if DMA3 source address was not zeroed), if checks since how much time the game has been powered on/reset. If that time is >18mn12seconds (ie. if the counter is >= 0x8000), it triggers the "MSoD" and resets. Note that the way the game checks the values at 0x020FB594~0x020FB597 looks weird because the timer0 value is used but not checked... So I guess it is used to "randomize" the 32-bits value at 0x020FB594.

And if you reset the game (Start+Select+L+R), the DMA3 value won't be zeroed for the real game anymore. So to avoid blocking the real game, upon resetting the game saves/restores the protection status value (enabled/disabled), and set a 'has been reset' flag. Then, when the game restarts, and after the DMA3 source has been checked, the game looks if the reset flag is set. If yes, it recomputes the value using the "original" (ie. upon start up) DMA3 source state (zeroed/not zeroed).

All of that means the real way to "manually patch" the game would be to make the game think the DMA3 source value is 0ed. That means for exemple changing the value at 0x020286FC (ram address) to 0x4280.

The patch/codes/devices firmwares upgrades that have been released just "kill" the counter that triggers the "MSoD". However, that counter is used for other in-game things (it is checked during FMVs for exemple, and it seems people report problem in shops), so it is definitly pretty dangerous to kill it. The real fix for the "devices" that get "blocked" would be to simply clear the DMA3 registers (actually clean anything they changed) before running the game...

And as AR codes are executed after the DMA3 source check is executed, killing that check is not possible with such codes. So here is a code that will kill the protection (when you go through doors) :

Kill Protection code : (ne rêvez pas, je ne laisse pas le code !)